home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20000824-20010305 / 000157_news@columbia.edu _Fri Dec 29 11:42:36 2000.msg < prev    next >
Internet Message Format  |  2020-01-01  |  5KB
  1. Return-Path: <news@columbia.edu>
  2. Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2])
  3.     by uhaligani.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA00805
  4.     for <kermit.misc@cpunix.cc.columbia.edu>; Fri, 29 Dec 2000 11:42:36 -0500 (EST)
  5. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
  6.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id LAA11632
  7.     for <kermit.misc@watsun.cc.columbia.edu>; Fri, 29 Dec 2000 11:42:35 -0500 (EST)
  8. Received: (from news@localhost)
  9.     by newsmaster.cc.columbia.edu (8.9.3/8.9.3) id LAA04056
  10.     for kermit.misc@watsun.cc.columbia.edu; Fri, 29 Dec 2000 11:28:15 -0500 (EST)
  11. X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
  12. From: fdc@columbia.edu (Frank da Cruz)
  13. Subject: Converting struct tm to time_t
  14. Date: 29 Dec 2000 16:28:13 GMT
  15. Organization: Columbia University
  16. Message-ID: <92ie2t$3ul$1@newsmaster.cc.columbia.edu>
  17. To: kermit.misc@columbia.edu
  18.  
  19. In article <92i02v$m4u$1@news01.si.uniovi.es>,
  20. Igor Sobrado  <sobrado@string1.ciencias.uniovi.es> wrote:
  21. : Frank da Cruz <fdc@watsun.cc.columbia.edu> wrote:
  22. : > In article <3A4BA47C.53C64EBA@srv.net>, Kevin Handy  <kth@srv.net> wrote:
  23. : > : Frank da Cruz wrote (about mktime()):
  24. : >
  25. : > 2. Doesn't do what you want.  "In addition to computing the calendar 
  26. : >    time, mktime() normalizes the supplied tm structure" -- applies
  27. : >    timezone conversions, etc.  The problem there is, of course, we
  28. : >    don't know, and have no way to find out, the server's timezone, and
  29. : >    even if we knew it, what the rules are to convert to our own.  The
  30. : >    struct tm is *already* in GMT/UTC, and should not be converted to
  31. : >    it again.
  32. : >
  33. : > Thus the resulting file date won't be what you want.  I think the
  34. : > object of copying the server's MDTM is so update can work in both
  35. : > directions.  If we use mktime(), I think the result will have up to 24
  36. : > hours of randomness added or subtracted.  Am I missing something?
  37. : 
  38. : As you noted, the FTP-server provides the time in UTC/GMT, all
  39. : Unix boxes work with that standard convention. The second (incorrect)
  40. : conversion to UTC is made locally by the host where C-Kermit
  41. : is installed because mktime(3C) supposes that the tm structure is
  42. : in local format, not it UTC. Why not calculate the UTC offset for
  43. : the time (as if it is in local format) and "correct" the time
  44. : either before converting it to a time_t structure or after that?
  45. : 
  46. This leads only to more difficulties.  The time-related APIs are the most
  47. twisted and crazed ones in UNIX, and vary significantly from platform to
  48. platform and version to version of the OS, C library, and compiler and
  49. header files.  How do you find out the timezone or GMT/UTC offset?  Is it
  50. an API call (gettimeofday() or what?), a global long, ulong, int, short,
  51. etc?  A global struct timezone?  And/or is it extern time_t tzoffset?  A
  52. member of struct tm?  Obtained how?  And what are the units?  And can you
  53. believe them?  Do they or do they not account for daylight savings time?
  54. If not, how do we compensate?  Here's a typical man page quote:
  55.  
  56.      The external long variable timezone contains the difference,
  57.      in  seconds,  between  GMT  and local standard time (in PST,
  58.      timezone is 8*60*60).  If this difference is not a constant,
  59.      timezone  will contain the value of the offset on January 1,
  60.      1970 at 00:00 GMT. Since this is not necessarily the same as
  61.      the  value  at  some  particular  time, the time in question
  62.      should be converted to a tm structure using localtime()  and
  63.      the  tm_gmtoff  field of that structure should be used.  The
  64.      external variable daylight is non-zero if and only  if  Day-
  65.      light  Savings  Time  would  be in effect within the current
  66.      time zone at some time; it does not  indicate  whether  Day-
  67.      light Savings Time is currently in effect.
  68.  
  69. This would not be encouraging even if it applied to every platform,
  70. but it's only for one release of one OS.  In many OS's (e.g. BSDI) the
  71. variables and structs stay the same but their meaning changes from one
  72. release to the next.  In other OS's the structs and variables change, the
  73. header files move, and every other manner of obstacle can be expected.
  74.  
  75. In fact, I can try to program all this, but to make it compile, link, and
  76. run correctly on hundreds of platforms is not going to be pleasant, as you
  77. can already tell by looking at the other time-related code in cku[ft]io.c.
  78.  
  79. If anybody has any helpful or simplifying suggestions, I'd be glad to
  80. hear them.  The question is:
  81.  
  82.   How to convert a struct tm (which already is expressed in GMT) to
  83.   a time_t which expresses the clock time in GMT (not local time) in
  84.   a way that is reliable (works in any timezone and takes daylight
  85.   savings into account) and is portable to as many UNIX platforms as
  86.   possible (and how to do the same things on the platforms to which
  87.   this portability does not extend)?  The answer (as noted previously)
  88.   is not mktime(), since it presumes its argument is in local time,
  89.   not GMT.
  90.  
  91. I'll copy this to comp.unix.programmer.
  92.  
  93. - Frank